The STL++ Coordination Language: A Base for Implementing Distributed Multi-agent Applications

Port NewBrokerAss_Evt Event STLpp Entity TradeSystem_B Worker PrivateCustomer CompanyCustomer TradeMemberCompany_B Secretary TradeManager BrokerAssistant Broker Blop Agent KK_Blop_inPort KK_Blop_outPort S_Blop_inPort S_Blop_outPort KK_outPort S_inPort S_outPort S_Blop_Port KK_Blop_Port Group_Blop_Port Stream_Blop_Port Blop_Port Process_Port BB_Port Group_Port Stream_Port KK_Port S_Port KK_inPort Port AccessedCond GetAccessedCond PutAccessedCond TerminatedCond MsgHandledCond UnboundCond SaturatedCond Customer Fig. 2. STL++ user classes together with classes of the application presented in section 4 (bold italic). Agent termination is implicit: the agent disappears along with its ports and data, when the corresponding Agent object terminates. Regarding the implementation, an Agent object is embedded in a light-weight process (thread). Ports and Connections. In accordance with the ECM model, every port is endowed with one or several names and a set of features. STL++ distinguishes Primary and Secondary Features for ports. Primary Features, which de ne the main semantics of a port, and therefore the basic port types, encompass: i) Communication: this feature captures ECM communication paradigms; ii) Msg Synchronization: this feature gives to the connection the usual semantics of message passing communication. Possible values are synchron and asynchron; iii) Orientation: this feature de nes the direction of the data ow over a connection; there are three possible values, namely in (inowing), out (outowing) and inout (bi-directional). Port Type Communication Msg Synchronization Orientation Blackboard blackboard asynchron inout Group group asynchron inout S-Stream stream synchron in or out KK-Stream stream asynchron in or out Table 1. Basic port types and values of their primary features. Secondary Features, which de ne characteristics for speci c types of ports, are: i) Saturation: this feature, ranging from 1 to INF (in nity) by integer values, de nes the number of connections a port can have; ii) Lifetime: this feature, ranging from 1 to INF (in nity) by integer values, indicates the number of data units that can pass through a port before it decays; iii) Data Type: this feature de nes the type of data authorized to pass through a port. STL++ currently supports four basic port types, corresponding to the combinations of the primary features as displayed in Table 1. Note that, provided that ports match, it yields four basic connection types. Blackboard port type. The resulting connection, as a result of the matching of ports of this type, has a blackboard semantics. The number of participating ports is unlimited. Messages are persistent objects which can be retrieved using a symbolic name. Moreover, messages are not ordered. To access the blackboard, the following Linda-like primitives are provided: put (non-blocking), get (blocking) and read (blocking). Blackboard connections are persistent: if all the ports involved in a blackboard connection disappear, the connection still persists in the blop space with all the information it carries, so that new ports can later on reconnect to the blackboard and recover the pending information. Group port type. The resulting connection has a closed group semantics. The number of participating ports is unlimited. Each member of the group can broadcast asynchronously messages to every participant in the group. Messages are stored at the receiver side. Thus, if a port in a group disappears, then the sequence of information that has not been read is lost. The primitives for accessing the group are: get (blocking) and put (non-blocking). S-Stream port type. The semantics of a connection resulting from the matching of two S-Stream ports (S for synchronous) has the same semantics as the S-Channel de ned in [2], in particular this connection is uni-directional. This connection always results from the matching of contradictory oriented ports, namely a producer and a consumer. In contrast to other connections, this connection never contains data, due to its synchronous nature. So the destruction of the producer or the consumer never causes loss of data. The primitives for accessing the port are get (blocking) and put (blocking). KK-Stream port type. The semantics of a connection resulting from the matching of two KK-Stream ports (K for keep) is analogous to the asynchronous KK-Channel de ned in [2], with its semantics (see below) when a port disappears from one end of the connection. As for S-Streams, this connection always results from the matching of contradictory oriented ports. If the connection is broken at Feature F Values Compatibility Communication blackboard, stream, group P1.F = P2.F Msg. Synchronization synchron, asynchron P1.F = P2.F Orientation in, out, inout (P1.F = in and P2.F = out) or (P1.F = P2.F = inout) Saturation {1,2,...,INF} Always compatible Data Type Type P1.F = P2.F Lifetime {1,2,...,INF} Always compatible Table 2. Compatibility for Features F for two Ports P1 and P2 its consuming port, the next new matching port will consume all pending data. If the connection is broken at its producing port, the consuming port will be able to continue to consume all data in the connection. If both ports are deleted, the connection disappears with its data. The primitives for accessing the port are get (blocking) and put (non-blocking). Establishing Connections between Agents. Communication between agents is realized through connections which are the result of matched ports. In accordance with the ECM model, the matching is realized as a relation between port signatures. In STL++, in order to match, ports must belong to the same blop and must comply at name and type levels: i) Name level. Two ports match at name level if they share at least one name. A port may have several names; in this case, each name belongs to a di erent connection; ii) Type level. For two ports, values of the same feature must be compatible. Table 2 gives an overview of the compatibility functions used by the STL++ runtime system. By introducing several names for each port, STL++ allows stream and group ports to be connected to di erent connections (blackboard ports cannot have multiple connections). Data written on such multiple connection ports are echoed on every connection. For stream connections, 1:1, 1:n, n:1 and n:m communication patterns can be built. Likewise, several groups can be connected to a single port. Events. Event classes inherit from Event; the launch() method, which de nes the acting of the event, must be re-implemented. Events are instantiated with a speci c lifetime which determines how many times they can be triggered. Conditions on ports (see table 3 for an overview) are checked when data ow through the port, or, in the case of saturatedCond condition, when a new connection is realized. 4 Simulation of a Trading System The numerous activities that take place within a trading system are typically distributed and can be modeled by a multi-agent system. It has led solutions Condition Explanation UnboundCond() Port not connected. SaturatedCond() Port saturated. MsgHandledCond(int n) Port has handled n messages. AccessedCond() Port accessed. PutAccessedCond() Port accessed with put primitive. GetAccessedCond() Port accessed with get primitive. TerminatedCond() Port lifetime is over. Table 3. Port Conditions for agent-based electronic commerce; see for instance Kasbah [13], FishMarket [35], or a proposal based on the PageSpace platform [14]. If our goal is to fully automate a trading system, for the time being, we would rather concentrate on simulating the automation of such a system. Our aim, in this paper, is not to focus on the control algorithms of the di erent agents, nor on the negotiation techniques (see e.g. [21]) that are undertaken by the agents in order to process a transaction, but rather to concentrate on the basic coordination mechanisms that come into play in the interactions between agents, for which STL++ is precisely suitable. Thus, in this implementation, agents are endowed with a very basic autonomy [12] in the sense that they can make decisions on their own, without user intervention. More sophisticated autonomy-based control algorithms and smart negotiation techniques will be tackled in a further stage. Figure 3 gives a scaled down graphical overview of the organization of the agents that compose our trading system, as well as their interactions. To avoid cluttering the graph, port names (on which the matching is based) have been intentionally omitted. The TradeWorld blop con nes every activity in the trading simulation. Several Trading System blops (TSB) are accessible by customers (company or private customers), who are authorized members of a trading system that represent end-user agents. Company or Private Customers create queries to buy or sell goods. These queries, written by the customer on his query P port (of KK outPort type), are transmitted to a Trading System Blop (TSB). In a TSB reside Brokers, each of whom is devoted to serve a particular customer, by handling his committed customer queries that came in. A pair of ports on the TSB, namely name query gate P and name res gate P (name being off1 or off2 in gure 3), serves as gates for each customer and his respective broker. Every query is then posted by the broker to his trade P port (of BB Port type), e.g., sell 100 securities at 1000 CHF and therefore published in the Trade Unit Blackboard. On the trade P port is bound the event NewBrokerAss Evt with the condition PutAccessedCond; the e ect of the posting is that the NewBrokerAss Evt event is triggered. The role of this event is to dynamically create a Broker Assistant that will be in charge of ful lling the speci c query, by establishing a dynamic connection with another broker assisTrade Member Company Blop Secretary Broker Trade Unit Blackboard Trade Manager Trading System Blop (TSB) Private Customer query_gate_P Transaction Results Blackboard result_gate_P query_P result_P query_P result_P off1_query_gate_P off1_res_gate_P off2_query_gate_p off2_res_gate_P trade_P query_P trade_P TradeWorld Broker Assistant result_P trade_P trade_partner_o_P trade_partner_i_P NewBrokerAss_Evt trade_P Broker Assistant result_P trade_partner_o_P trade_partner_i_P query_P trade_P Broker lt Company Customer result_P query_P Fig. 3. Trading System with STL++. tant interested in an (almost) symmetric query (e.g., buy 50 securities at 1000 CHF). This is possible on the basis of the information transmitted by the Trade Manager. All queries are supervised by the Trade Manager; he knows who issued which query (through an identi cation contained in the query). For each new arrived query, the Trade Manager checks whether a possible matching between proposals can take place (e.g. case of a broker who wants to buy securities of type A and another broker who wants to sell securities of type A). If a kind of matching can somehow be issued between two Broker Assistants, the Trade Manager puts on the Trade Unit Blackboard two appropriate messages for each involved Broker Assistant. The information transmitted contains among others a speci c transaction id. A newly created Broker Assistant has rst to read from his trade P port (of type BB Port) in order to be informed of a speci c transaction. In virtue of this information, he dynamically publishes two KK Ports using the transaction id as port name (trade partner i P and trade partner o P ports). A new double connection is then established between these two partners. Both involved Broker Assistants exchange useful information so as to make their query successful (this is precisely where negotiation techniques appear). When a successful transaction (the result of the agreement of two Broker Assistants) is issued, both Broker Assistants inform their committed customers by transmitting appropriate information on their result P port (of type KK outPort), and then terminate. On customer side, results about processed queries can be collected either directly or through a Secretary Agent (see gure 3). At regular intervals, non ful lled queries are eliminated by the Trade Manager; all involved entities are kept posted. 5 Discussion 5.1 STL++ a Coordination Language ECM, a coordination model for distributed programming, along with STL++ its instantiation, present some similarities with e.g. the IWIM [2] coordination model and its instance Manifold [3], Linda [8], Darwin [28] or ConCoord [22]. Though ECM shares many characteristics with IWIM, it however di ers in several points: i) Blops are not coordinators like IWIM managers. Connections are not established explicitly by the blop (or by another agent), i.e. there is no language construct to bind ports in order to establish a connection: the establishment of connections is done implicitly, resulting from a matching mechanism between compatible ports within the same blop; the matching depends on the types and the states of the concerned ports. The main characteristics of blops is to encapsulate objects, thus forming a separate name-space for enclosed entities and an encapsulation mechanism for events; ii) ECM generalizes connection types, namely stream, blackboard or group, and does not restrict to channels; iii) In ECM, events are not signals broadcast in the environment, but objects that realize an action in a blop. Events are attached to ports with conditions on their state that determine when they are to be launched. They can create agents or blops, and their action area is limited to a blop. ECM together with STL++ di er in the following points from Linda: i) Like several further developments of the Linda model (e.g. [25]), ECM uses a hierarchical multiple coordination space model [18], in contrast to the single at tuple space of the original Linda. But it has to be stressed that a blop is not a shared dataspace as a tuple space, but an abstraction mechanism of several agents that serves as a separate name space; ii) In STL++ agents get started through an event in a blop, or automatically upon initialization of a blop, or through a creation operation by another agent; Linda uses a single mechanism: eval(). The termination of an agent results in the loss of all its enclosed dataand ports; it may as well result in the loss of pending data in the case of un-bound connections. (see section 3). In Linda, a tuple replaces the terminatedprocess; iii) In STL++ agents do not execute in a medium which is used totransfer data. Every communication is realized through connections establishedby the matching of ports. Only the engaged agents have access to those connec-tions; iv) Blackboard connections allow for generative communication betweenthe participating agents. For the time being, a string is used to introduce andretrieve data. Neither tuples, nor templates, nor pattern matching are supportedfor retrieving data. Blackboards are typed in the sense that only one type of datacan be entered. There is also no kind of active tuples.5.2 Implementing Coordination in MAS with STL++STL++ can be considered as a preliminary language for constructing agent ap-plications, stressing the coordination part of a MAS. In its purpose, STL++is comparable to APRIL [30], conceived as a platform oriented towards the im-plementation of MAS, and to Bauhaus Linda [10], which has been applied toimplementing Turingware, a superset of Groupware.STL++ has some characteristics that make it a good candidate for imple-menting MAS: i) Blops constitute a mechanism which enables construction ofa structured set of di erent environments, each of which is a closed private co-ordination space with communication interfaces to other environments. A setof complex interconnected and hierarchically organized spaces is indeed oftendesirable in MAS; ii) Autonomous agents are implemented as black boxes. Anautonomous agent owns exclusive control over its internal state and behavior; itcan de ne by itself its ports. It is seen from external views (its environment) as adelineated entity presenting clear interfaces. Being distinct from the outside (theenvironment), an agent is part of its environment composed by its surroundingblop and the agents living in it. iii) Sensing and acting capacities of agents areimplemented with ports. Thus agents can perceive and act through di erentmeans, by virtue of the possibility to de ne port types and several instantiationsof them. A port perceives speci c data; this is enforced with the data type fea-ture of ports. iv) As agents and environments may evolve over time, dynamicityis an important point in MAS. This has led to design STL++ so as to supportblop reorganization, new port creation and destruction, thus yielding dynamiccommunication topologies.6 ConclusionIn r esum e, we presented the ECM coordination model and STL++, an in-stantiation that constitutes a platform to implement Multi-Agent Systems. AnSTL++ implementation of a simulation of a Trading System showed the poten-tial of our coordination language. Future work will consist of: i) Extending STL++ so as to support genericcoordination patterns, yielding templates at disposal for general purpose imple-mentations; ii) Enhancing the Trading System simulation so as to tackle moresophisticated autonomy-based control algorithms and smart negotiation tech-niques. We also work on a new ECM mapping in Java built on the ORBacusObject Request Broker [32] and the JavaSpaces [37] API.References1. G. Agha. ACTORS: A Model of Concurrent Computation in Distributed Systems.MIT Press, 1986.2. F. Arbab. The IWIM Model for Coordination of Concurrent Activities. In P. Cian-carini and C. Hankin, editors, Proceedings of the First International Conference onCoordination Models, Languages and Applications, number 1061 in LNCS. SpringerVerlag, April 1996.3. F. Arbab, I. Herman, and P. Spilling. An Overview of Manifold and its Implemen-tation. Concurrency: Practice and Experience, 5(1):23{70, February 1993.4. J.P. Banâtre and D. Le Metayer. Programming by Multiset Transformation. Com-munications of the ACM, 36(1):98{111, 1993.5. M. Bourgois, J.M. Andreoli, and R. Pareschi. Extending Objects with Rules,Composition and Concurrency: the LO Experience. Technical report, EuropeanComputer Industry Research Centre, Munich, Germany, 1992.6. S. Bussmann and J. Muller. A Negotiation Framework for Co-operating Agents. InS. M. Deen, editor, Proceedings of CKBS-SIG, pages 1{17. Dake Centre, Universityof Keele, 1992.7. N. Carriero, E. Freeman, D. Gelernter, and D. Kaminsky. Adaptive Parallelismand Piranha. IEEE Computer, 28(1), January 1995.8. N. Carriero and D. Gelernter. Linda in Context. Communications of the ACM,32(4):444{458, 1989.9. N. Carriero and D. Gelernter. Coordination Languages and Their Signi cance.Communications of the ACM, 35(2):97{107, February 1992.10. N. Carriero, D. Gelernter, and S. Hupfer. Collaborative Applications Experiencewith the Bauhaus Coordination Language. In R. H. Sprague Jr., editor, Proceed-ings of the 30th Hawaii International Conference on System Sciences, volume 1,Wailea, Hawaii, 1997. IEEE. Minitrack on Coordination Languages, Systems andApplications.11. N. Carriero, D. Gelernter, and L. Zuck. Bauhaus Linda. In P. Ciancarini, O. Nier-strasz, and A. Yonezawa, editors, Object-Based Models and Languages for Con-current Systems, volume 924 of Lecture Notes in Computer Science, Berlin, 1995.Springer Verlag.12. F. Chantemargue, O. Krone, M. Schumacher, T. Dagae , and B. Hirsbrunner.Autonomous Agents: from Concepts to Implementation. In Proceedings of theFourteenth European Meeting on Cybernetics and Systems Research (EMCSR'98),volume 2, pages 731{736, Vienna, Austria, April 14-17 1998.13. A. Chavez and P. Maes. Kasbah: An Agent Marketplace for Buying and SellingGoods. In Proceedings of the First International Conference on the Practical Appli-cation of Intelligent Agents and Multi-Agent Technology, London, UK, April 1996.Lawrence Erlbaum. 14. P. Ciancarini, A. Knoche, D. Rossi, R. Tolksdorf, and F. Vitali. CoordinatingJava agents for Financial Applications on the WWW. In Proceedings of the SecondInternational Conference and Exhibition on The Practical Application of IntelligentAgents and Multi-Agents, PAAM '97, 1997.15. P. Ciancarini, A. Knoche, R. Tolksdorf, and Fabio Vitali. PageSpace: An Archi-tecture to Coordinate Distributed Applications on the Web. In Proceedings of theFifth International World Wide Web Conference, volume 28 of Computer Networksand ISDN Systems, 1996.16. T. Finin, R. Fritzon, D. McKay, and R. McEntire. KQML as an Agent Communica-tion Language. In Proceedings of the 3rd International Conference on Informationand Knowledge Management (CIKM). ACM Press, 1994.17. S. Franklin and A. Graesser. Is it an Agent or just a Program? A Taxonomy forAutonomous Agents. In J.P. Muller, M.J. Wooldridge, and N.R. Jennings, editors,Proceedings of ECAI'96 Workshop (ATAL). Intelligent Agents III. Agent Theories,Architectures, and Languages, number 1193 in LNAI, pages 21{35, August 1996.18. D. Gelernter. Mulitiple Tuple Spaces in Linda. In E. Odijk, M. Rem, and J.Syre,editors, Proceedings of the Conference on Parallel Architectures and LanguagesEurope (PARLE 89), volume 365 of Lecture Notes in Computer Science, pages20{27, Berlin, 1989. Springer Verlag.19. M.R. Genesereth and R.E. Fikes. Knowledge Interchange Format, Version 3.0.Reference Manual. Technical Report Logic-92-1, Computer Science Department,Stanford university, 1992.20. T.R. Gruber. A Translation Approach to Portable Ontology Speci cations. Knowl-edge Acquisition, 5:119{220, 1993.21. R. Guttman and P. Maes. Cooperative vs. Competitive Multi-Agent Negotiationsin Retail Electronic Commerce. In Proceedings of the Second International Work-shop on Cooperative Information Agents (CIA'98)., July 1998.22. A.A. Holzbacher. A Software Environment for Concurrent Coordinated Program-ming. In P. Ciancarini and C. Hankin, editors, Proceedings of the First Interna-tional Conference on Coordination Models, Languages and Applications, number1061 in LNCS. Springer Verlag, April 1996.23. L. Lee H.S. Nwana and N.R. Jennings. Co-ordination in Multi-Agent Systems. InH. S. Nwana and N. Azarmi, editors, Software Agents and Soft Computing, number1198 in LNAI. Springer Verlag, 1997.24. Y. Jin and T. Koyoma. Multi-agent Planning through Expectation-based Negoti-ation. In Proceedings of the 10th Int Workshop on DAI, Texas, 1990.25. T. Kielmann. Objective Linda: A Coordination Model for Object-Oriented ParallelProgramming. PhD thesis, Dept. of Electrical Engineering and Computer Science,University of Siegen, Germany, 1997.26. O. Krone, F. Chantemargue, T. Dagae , and M. Schumacher. Coordinating Au-tonomous Entities with STL. The Applied Computing Review, Special issue onCoordination Models Languages and Applications, 1998.27. O. Krone, B. Hirsbrunner, and V.S. Sunderam. PT-PVM+: A Portable Platformfor Multithreaded Coordination Languages. Calculateurs Paralleles, 8(2):167{182,1996.28. J. Magee, N.Dulay, and J. Kramer. Structuring parallel and distributed programs.Software Engineering Journal, pages 73{82, March 1993.29. T.W. Malone and K. Crowston. The Interdisciplinary Study of Coordination. ACMComputing Surveys, 26(1):87{119, March 1994. 30. F.G. McCabe and K.L. Clark. April agent process interaction language. InM. Wooldridge and N.R. Jennings, editors, Intelligent Agents. Proceedings ofFirst International Workshop on Agent Theories, Architectures, and Languages(ATAL'94), number 890 in LNAI. Springer Verlag, August 1994.31. R. De Nicola, G. Ferrari, and R. Pugliese. Coordinating mobile agents via black-boards and access rights. In Proceedings of the 2nd International Conference onCoordination Languages and Models (Coordination '97), number 1282 in LNCS.Springer Verlag, September 1997.32. ORBacus Object Request Broker. Object Oriented Concepts, Inc., 1999.www.ooc.com.33. G.A. Papadopoulos and F. Arbab. Coordination Models and Languages. InM. Zelkowitz, editor, Advances in Computers, The Engineering of Large Systems,volume 46. Academic Press, August 1998.34. A. Rawston and A. Wood. Bonita: A Set of Tuple Space primitives for DistributedCoordination. In R. H. Sprague Jr., editor, Proceedings of the 30th Hawaii Inter-national Conference on System Sciences, volume 1, Wailea, Hawaii, 1997. IEEE.Minitrack on Coordination Languages, Systems and Applications.35. J. A. Rodriguez-Aguilar, P. Noriega, C. Sierra, and J. Padget. Fm96.5 a java-basedelectronic auction house. In Proceedings of the Second International Conferenceon The Practical Application of Intelligent Agents and Multi-Agent Technology(PAAM'97), 1997.36. J. Searle. Speech Acts. Cambridge University Press, 1969.37. Sun Microsystems, Inc. JavaSpaces TM Speci cation, Revision 1.0, March 1998.38. R. van der Goot, J. Schae er, and G.V. Wilson. Safer tuple spaces. In Proceed-ings of the 2nd International Conference on Coordination Languages and Models(Coordination '97), number 1282 in LNCS. Springer Verlag, September 1997.39. K.J. Werkman. Knowledge-based Model of Negotiation using Shareable Perspec-tives. In Proceedings of the 10th Int Workshop on DAI, 1990.40. M. Wooldridge and N.R. Jennings. Agent Theories, Architectures, and Languages:a Survey. In M. Wooldridge and N.R. Jennings, editors, Intelligent Agents, number890 in LNCS, pages 1{39. Springer Verlag, 1995.